Thank you for watching.
Thank you for watching.
Thank you for watching.
I'm proud to see as many people as I do here.
You are obviously the hardcore who are both awake and have not left after checkout time,
so thank you for coming.
So, basically, my talk today is on 8-bit microcontrollers.
I'll be going over a bunch of different aspects of them.
It's kind of a shotgun presentation.
I am Phil King, and the reason I might have something useful to say about this
is because I'm a hardware engineer who's been designing with these things on and off for over a decade now.
I am also an enthusiast who's building all sorts of weird things at any given time,
and I actually have taught a course on this stuff, so I picked up some idea of what to present.
The forum here is really different than I'm used to,
so there will be glitches, and I ask you to indulge me.
If there's anything you need to know, please raise your hand.
I will be taking questions throughout, but I also have a Q&A period at the end,
and the reason you should be interested in what I have to say
is because we've got some really neat stuff you can do with 8-bit systems,
8-bit microcontrollers, and, of course, free stuff.
Since that's always...
Yeah?
Yeah.
I'll be getting...
He asks,
They aren't yet, they will be, and the URL is at the end of the presentation.
So they will be available.
You don't need to write all this crap down.
With regard to getting free stuff, since that's what you're all wondering about since I mentioned that last,
the free stuff specifically is an Atmel STK100 starter kit.
They are these things.
This is the hardware that I have developed this presentation around.
They're a really slick little kit.
I don't even know off the top of my head what the price of these things is.
Retail?
I think they're about $150.
But I've got some of them to give away, and there's two different ways to get one.
You can either suggest a project idea during the Q&A period,
in which case we will...
Be prepared to elaborate, and I'd like to discuss ideas,
and I may or may not invoke the audience to give you the thumbs up or thumbs down
on whether your idea merits a starter kit.
And then the other way is to get a starter kit by submitting a feedback form with a project idea.
And this is if you're not willing to hold your project up to public humiliation,
feel free to write down the feedback information at the end.
This is basically the way I bribe my audience to give me recommendations on how to make these talks better.
I've been doing variations on this for a while now,
and hopefully it's evolving and getting better.
But if it sucks, I need to know that.
So, specifically, what am I going to hit on?
I'm going to hit on what are microcontrollers?
Presumably, if you're here, you have a pretty good idea what that is,
so I'm not going to dwell on that real long.
Why am I focusing on the tiny ones?
The talk title is Eight Pins and Eight Bits,
and I'll get into what exactly that means in terms of the starter kit shortly.
What can they do?
What exact functionality do you have in these things?
What are the development tools?
Both what am I using and what if you want to be using something else?
And then I'll do a bunch of application examples.
I don't have specific demonstrations of most of the application examples
because a lot of them are derived from other people's projects, application notes, things like that.
And instead, I look at them in terms of putting them on this hardware
and what you would want to do.
What would you want to do to adapt them to your needs?
And then finally, the Q&A period at the end.
Always got to have one of those.
Okay, so what exactly is a microcontroller?
Some of you are actually old enough to have started out working like I did on 8-bit computers
before Intel ruled the world.
Was that a 4?
A 4-bit.
Impressive.
But there was a time when 8-bits was what you needed.
And that's what you got, at least in anything that had a single-piece processor.
Now, most 8-bit processors, which, by the way, still represent the largest market share
in terms of number of CPU core shipping, are found almost entirely in microcontrollers,
which is an 8-bit CPU core together with a bunch of resources stuck around it.
And the common canonical examples are memory.
For example, some ROM or Flash or EEPROM ports, which are programmable I.O.,
where they've generally taken all of the internal bussing to the processor,
kept it in the chip, and then they give you some ports out to pins
so you can twiddle individual electrical connections as I.O. ports
rather than dealing with them as memory-mapped I.O.
And then a variety of peripherals, depending on what you're using.
I mentioned timer, interrupt controller.
These are sort of the basic ones.
Larger microcontrollers will have more.
I'm dealing with really, really small ones.
And then generally, a microcontroller is a self-contained architecture,
requiring only a few other components,
or in the case of some of these parts, literally no other components to build a system.
So why am I so obsessed with the tiny ones, little 8-pin, 8-bit jobbies?
First of all, because we can.
It's really cool to see what you can do with a part that has only 8 wires coming out of it.
Also, learning to make use of minimal resources.
There are some folks in the demo crowd who know that 1K is a lot of program space,
but there are a lot of people who have gotten away from the roots,
so it's fun to see what you can do in a very small, very small package,
both in terms of physically and in terms of code space.
And then minimal wiring.
And I put that up kind of as a joke, but when you've only got 8 pins,
there's just not that much wire you're going to need.
And if you hate soldering things together, or you hate wire wrapping,
this is a good way to keep the wire count down.
So what are some of these interesting minimal systems?
And one category I sort of synthetically lumped a lot of them into is implants,
which are things you want it to be small enough that you can put it places,
people won't notice it, that it's unobtrusive, or that it fits inside some existing system.
So, bugs or portable stuff.
Another, essentially, arguably an implant also, but a separate category is mod chips.
And I will sort of glance over that, but I know that's of interest to at least some of this crowd.
And then telemetry devices.
One of the things that came out in the project discussions last year is a lot of people said,
I want to build a telemetry widget for blah.
And so that's a really good application
for a really small controller where you want to collect a few bits of data
and either log it or send it off over over a link somehow.
And so what are the 8-pin microcontrollers?
If you look at the whole family, the ones that I have been able to track down,
there may be others I have overlooked, if so, I apologize, and feel free to add them to the heap,
but the common ones available now are the Atmel AT-Tiny series and a couple of the other AT series,
and then the Microchip PIC-12C,
and I believe they've just come out,
with an 8-pin version of either the 14 or the 16C.
There are also, that's why I said there's a few other PICs.
I'm going to be focusing on the Atmel AVRs.
Like so many things in this world, your choice of processor,
your choice of microcontroller rapidly becomes a religious topic.
I like the AVR because it's got some neat features
and because I can get free development hardware for them.
Yeah, the PIC is also a good part.
A lot of people have a lot of experience with the PIC,
but I'm just going to be running off.
I'm going to be running off on the AVR
and showing you what you can do with this board.
So the common features to the AVR architecture,
whether they're the 8-pin or not,
are that it's a RISC instruction set.
The closest you may have run into
if you haven't done microcontroller development is MIPS,
the MIPS RISC instruction set.
It's a Harvard architecture,
meaning that you have separate code and data space.
There's 32 general purpose registers,
although as with most 32 general purpose registers,
they're not all quite general.
And then there's a status register,
and then there's a set of I.O. registers
that vary from part to part.
But every one of them has a block of I.O. space.
Some of the features of the RISC instruction set
that make it really good,
even for a small application like this,
is simple fixed length instructions.
In the AVR instruction set,
virtually everything is a 16-bit word,
which means that when you get the pipeline,
the execution pipeline full,
they're able to click along at one cycle per instruction.
If you've done any development with, say, an 8051,
depending on the implementation,
the 8051 will run up to 12 cycles per instruction,
which really starts to bog it down.
It's nice that you can run an AVR at one megahertz
and get, in the best possible case, one MIPS out of it.
And then it's a load store architecture,
meaning that anything you want to manipulate,
you drag into a register, you twiddle it,
you shove it back out.
There are no direct operations on memory.
Some of the general purpose register oddities,
I mentioned that they're not all quite equal.
If you do a load from data in program space,
and that may sound a little odd,
but there is a special instruction called LPM
for loading constants that you've stored
in your flash code space.
They get explicitly loaded to R0.
That's hardwired into it.
If you do a load immediate,
because of the way the instruction is set up,
if you think about it, you've got 16 bits
for this instruction word.
If you're doing a load immediate,
eight of them are taken up with the immediate value,
and some of them have to be for the op.
They wanted four of them for the op,
which means they've only got four bits left over
for the register description,
which means that you can actually only address
16 registers for immediate instruction,
so they arbitrarily chose the upper half of the register set.
So you get R16 to R31 if you want to do a load immediate.
You cannot load immediate into R0 to R15.
And then there are several,
two register indices that are set up.
In the case of the small parts,
the only one that they implement is the Z index,
which is the concatenation of R30 and R31.
And to give you an idea of how this stuff all maps together,
there is data space which has the register file
also at the top of data space,
which means you can access registers
by doing memory access,
and you can treat the registers as a block of SRAM,
which is useful because some of the parts
have no other SRAM, and in fact,
they've only got 32 bytes of SRAM in the register file.
They also map the I.O. registers,
which have their own sort of pseudo I.O. space
immediately after the register file.
So on all of the AVR parts,
the data address space is known to be
the first 0 to 1F is going to be your register file,
and 20 to 5F is going to be your I.O. space.
SRAM, if there is any, begins after that.
External SRAM,
if the chip supports any,
and none of these do,
some of the larger ones do,
happens after that.
So the specific features of the AT-Tiny11,
the part that we're looking at,
are it's an 8-pin DIP or SOIC package.
I have some pictures later on.
I don't know if everyone here is familiar with an 8-pin DIP.
It's a really standard package.
It's relatively small.
If you want it smaller,
you can go to the surface mount SOIC.
There are six I.O. lines available.
Or actually, I should say five I.O. and one input,
if you disable the reset.
If you think about it,
that means you've got six I.O. and power and ground.
So it's making good use of its pins.
And then in this particular part,
you've got 1K byte of code flash,
because it's a 16-bit instruction word
that's 512 instruction words.
And some of you are thinking,
what can you possibly do with 512 words?
Some of you are probably thinking,
why?
Well, that's a ton of space.
The truth lies somewhere in the middle,
and I'll touch on some of the cool things you can do
in a relatively small space.
When I'm talking about the applications.
More features.
There's a variety of speed grades available
for the ATtiny11.
And you can sort of map into a space
of what power and speed performance you want.
You can run them up to six megahertz.
The ATtiny11 specifically comes in speed grades
up to six megahertz at five volts.
And then in lower voltage versions that run,
for example, down to 2.7 volts
at two megahertz.
Another nice thing about this is
it's a fully static CMOS implementation,
meaning that you can actually run the clock
all the way down to zero.
It's got a couple of standby power modes
that will turn itself off,
and it can also be set to wake on interrupt,
which means if you know the next behavior
the system wants to respond to
is something outside of itself,
it can actually just put itself to sleep,
and it will wake up on an external interrupt.
And you can drop the power consumption
down to a few microamps.
And then even when it's running,
running relatively fast,
it's fairly low power.
And then I quote the data sheet
at less than five milliamps
at one megahertz at five volts.
If you bring the voltage down,
you can bring the power down within reason.
There's some other implications
to running the voltage at different levels,
and I'll touch on those briefly later.
It also has a whole bunch of different clocking options,
and this is kind of cool as well,
because when you're building a minimal system,
you don't want to have to hang an oscillator off this thing.
You can.
You can externally clock it.
You can stick an external crystal,
and it actually has an oscillator amplifier circuit
built into it.
In that case, you burn two of your eight pins
just sticking a crystal on it.
If you only need four, that's fine.
If you want to hook an external oscillator up to it,
you can do it with only one pin.
In that case, it's just the input, the clock input.
You can also do it with zero pins
with the onboard RC oscillator.
The upside is it takes zero pins,
and it runs at one megahertz at five volts,
although it runs at 350 kilohertz at three volts.
It runs at 110 kilohertz at two volts.
It runs at 1.1 megahertz at zero degrees Celsius.
It runs at 900 kilohertz at 70 degrees Celsius.
In other words, it's not regulated.
It's going to drift all over the place.
If you've got an application
where you're only interacting with people, this is okay.
If you've got an application
where you're doing asynchronous serial communication,
you may want a more stable clock.
The AT12 part, for example,
has a calibrated oscillator onboard,
and they actually test it at the factory
and guarantee the constraint of that one megahertz RC oscillator.
On the AT1011, it's going to drift all over the place.
The specific microcontroller resources
they've stuck on this particular part
are a hardware watchdog timer.
In this case, they actually run the watchdog timer
off the same oscillator as the self-clocking RC circuit.
So the watchdog runs at 1 megahertz,
and you can divide that down
by any of a whole bunch of pre-scale values,
or you can disable it.
If it's on and your system has turned on the watchdog
and fails to kick it before it times out,
the watchdog will trigger a reset.
This is useful if you're building a system
that you're afraid might go brain damage.
It's also useful if you're building a system
where you want to be able to time out on confusion,
and I'll touch on that later.
There's actually some good software system reasons
you might want a watchdog timer.
It's got an 8-bit counter timer.
It's a counter when you trigger it based on an input pin.
It's a timer when you hook it up to the clock,
and you can use this for doing all sorts of real-time
or quasi-real-time applications.
There is an analog comparator,
which allows you to get a single-bit comparison
of two analog inputs on two of your I.O. pins.
It can also generate an interrupt,
so if you want to be monitoring
the analog level and cause the system to wake up,
you can actually trigger on analog comparator fire.
And then the interrupt controller,
which hooks some of these together.
You have an external interrupt pin.
You've got an interrupt on any pin change.
You can actually cause the system to interrupt
when any of the external pins change value,
so they can effectively all be used as interrupt.
Obviously, you've got to be careful,
because you could interrupt a lot
if you've got that hooked up to a high-speed signal.
You've got timer counter overflow,
and then you've got the analog comparator.
What does it not have?
This is where the rubber meets the road
on some of the eight-pin stuff.
It has no SRAM beyond the general-purpose registers.
That means if you need more than 32 bytes to do anything,
this is not the part for you.
It does not support any sort of external SRAM.
Obviously, with eight pins,
you're not going to have a real big address data bus.
It also means that because there's no external SRAM,
the stack is three deep,
meaning it's real easy to blow it,
and it's implemented in hardware.
It's nine bits wide of custom hardware.
You cannot explicitly push or pop anything into the stack.
Only when you do calls will it stick the PC,
the program counter, into the stack.
Otherwise, the stack is effectively not there.
Also, if you do blow the stack,
it has the interesting behavior of wrapping around.
If you do a call, call, call, call,
you will have lost the first call return address,
and the fourth will now sit over the first.
It also has no hardware UART.
One of the things I talk about a little bit later
is implementing a software UART,
which is really quite doable.
It has no EEPROM storage.
That may seem a little non-sequitur,
but many of the parts do have a small chunk,
a third memory space that is EEPROM space
for storing lookup tables, constants.
This is a non-volatile space,
normally, that the part can write to.
In this case, it just isn't there.
And then there's no ATD converter.
You can add a serial ATD converter if you want,
or if you really need that, use a part that has it,
but this particular part doesn't.
What development tools am I using?
The assembler of choice I use is Atmel AVR Studio,
which is an integrated development environment
with an editor and an assembler.
It also includes a simulator,
so you can actually simulate your code,
obviously, within the constraints
of not having the hardware in the system.
If you're using the AVR Studio with this particular board,
you have to use a separate ISP package
in system programming,
and that allows you to program
through the parallel or serial port,
and then the development hardware,
as I talked about a little bit earlier,
is the STK100.
I don't know why I'm holding it up.
No one can see it when, in fact,
I have a slide of it in just a second.
There we go.
There is what the board looks like.
You see the parallel port
and serial port connections on the left side.
You've got a prototyping area on the right.
The stack of sockets about mid-board
is where you plug in the various parts.
You can see it supports
two flavors of 8-pin part
and then a 20 and a 28-pin.
There's also a microcontroller on it
that's doing the system programming.
Yeah?
Are there any OS requirements
for the development environment?
This particular OS only runs,
or this particular development only runs
under a rather unpopular OS.
There are other options,
and I'll touch on that in just a minute.
But a good question.
The white circular thing
is actually a piezoelectric speaker
that allows you to do sound output,
and I'll touch on that
as a neat application of these parts shortly.
And then another nice thing about this board
is it has its own power regulator built in,
so you feed it basically 7 to 20 volts AC or DC,
and it's any polarity of DC,
and it's fine with that.
As I mentioned,
it accommodates the 20 to 28 pins, provides,
oh, it also provides four LEDs and four buttons.
The fifth LED and button
were the power and reset, respectively.
And then there's various jumpers
next to all of the sockets
that allow you to turn on and off
some of the functionality.
If you want to wire things out directly,
the jumpers make great wire wrap posts.
And then this is a really good system
for getting a minimal development going.
But once you're going,
it's also really easy to transition
to a standalone device,
and in fact there's an ISP header
at the top of the board.
There's a header that allows you to use this board
to in-system program your own part
if you accommodate that in your design
in an external board.
Oh, and one other thing,
there's an IR transceiver pair on this thing
if you want to develop an IR remote control,
and I'll talk about that a little bit shortly.
Okay, so what if you hate this OS?
Or what if you want,
or why can't you use C?
Specifically cross assemblers,
and that's,
my preferred development tool,
are available for pretty much any OS.
The assemblers are relatively simple to write.
One of the nice things that falls out
of a RISC architecture
is the assemblers are pretty straightforward.
The ISP tools are also available.
I do not recall off the top of my head
what the preferred Linux ISP
or BSD ISP is.
I'll try to get pointers to those up on the website
fairly quickly. Yes?
A terminal emulator and a Z modem transfer
with the STK?
With this particular development environment?
Okay.
If you've got,
if you've got a minimal system,
I'm not sure if that will work
with this particular board.
It may.
I honestly don't know.
He suggested you can just do a Z modem,
was it Z modem transfer?
Okay.
Okay, to the part.
But the upshot of it is that
even though Canda,
who makes this board for Atmel,
does not publish this stuff widely enough,
it is readily available online.
And as far as C,
you can use,
there's a variety of C development environments.
A lot of people say,
well, you know,
C can be done efficiently,
and it in fact can.
IAR makes a third-party development set.
Unfortunately, that costs about 5K.
GCC, which actually arguably produces better code,
is available widely.
And,
it does,
it's really easy to set up a C environment.
I don't do it simply because I prefer to see
exactly what instructions I'm twiddling
and be able to run the simulator environment.
One of the things you've got to be aware of
when you're using C,
especially with a part like this,
some of the compilers will choke on this
simply because you have no SRAM,
and they really want a stack
to maintain stack frames.
And they get cranky when they've got no SRAM at all.
But,
they can do it.
Okay,
so what can you actually do?
What are some of my sample applications?
An AT keyboard interface,
a serial flash connection,
and audio output,
and some of the canonical audio examples
are Morse and DTMF.
Some other example modules would be a soft UART,
I alluded to that earlier,
data stream manipulator,
otherwise known as a mod chip,
an IR remote control,
or even a small parallel application,
in this case a 4-bit parallel application,
a stepper motor controller.
So the AT keyboard interface.
At this point, I'm going to delve into these.
I'm going to try to give you a sort of glancing overview
of a bunch of different things,
reference some of the application notes
you may want to look at.
If you have more questions,
feel free to raise them,
either now, Q&A, or after the talk.
But the AT keyboard interface,
for anyone who's looked at it,
is a synchronous serial interface,
meaning you have a clock and a data line.
It's very well documented, very straightforward.
It also includes 5-volt power with it.
This is really nice,
because it means that the AT connector
can power your little widget,
and you're well within the current limitations
of any device hanging off an AT port.
In fact, virtually every keyboard in the world
has a microcontroller in it,
which is just running an AT interface.
Most of them are 8051s,
because they were all designed back in about 1983,
ported over when AT became popular,
when XT became AT,
and then they largely haven't changed them.
It's a ROM-based microcontroller.
The QCAT makes a great housing
and a source of cable
if you're looking for a keyboard interface.
In taking apart the QCAT,
you will also learn some interesting truths.
One of them is that there is no direct electrical connection
between the keyboard in and keyboard out from the QCAT,
which means that it is at least handing along
and being aware of every keystroke.
This makes sense,
but it's also a little insidious
for reasons I'll get to momentarily.
So the Atmel reference AT keyboard interface
is Application Note 313.
They wrote it in C.
I went through it,
and I've done parts of it in assembly.
I haven't got that up and available online yet either,
but hopefully it will be.
They actually put the clock on the external interrupt line.
One of the nice things about the AT interface
is it has a maximum clock rate of, I believe,
around 100 kilohertz, 110 kilohertz,
which means you can actually,
it's slow enough,
you can just trigger an interrupt
every time a clock signal comes in
and read the bit.
Sample the data every interrupt,
and then it's possible to get out of sync
with the 11-bit frame that it sends
if you somehow miss a bit for some reason.
In that case,
what you generally want to do is timeout.
Their canonical example uses an 8-bit timer
for a 1.5 millisecond timeout,
and then this is where,
if you're clever and want to save a few bytes of code space,
you just set up the watchdog
to timeout after 15 milliseconds.
Every time you receive a bit
or you've gotten to the end of the 11-bit frame,
you kick the watchdog timer.
Otherwise, it'll get to 15 milliseconds.
It'll assume that it's gotten out of sync
and it'll timeout and reset.
What are some amusing widgets you could build
with just an 8-bit microcontroller
hooked up to an AT keyboard?
A few I came up with were the typo generator,
where you could have something
that sits on the keyboard line
and turns, say, every fourth R into a T
or just does minor transformations
in a non-obvious way on the keyboard stream.
This will annoy the hell out of anyone
who doesn't know that it's there.
Another that I would like to build
is the keyboard pipeline,
where it doesn't actually release a keystroke
until the next one,
so you've got a lag of keystroke in your keyboard.
And then something that's actually useful,
something that actually has some use,
would be a keyboard remapper.
You might want to do a QWERTY to VORAC
or a PC to Sun,
because a lot of people get cranky
about transposing caps lock and control
when they're changing keyboards.
So there are actually a lot of useful applications,
even with just the AT keyboard interface.
Yeah?
.
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Say you want a lot of memory.
A serial flash, for example.
Atmel makes this great little part.
It's the AT24C512.
It is 64k bytes of flash in an eight-pin DIP package.
It has, again, a two-wire bidirectional interface.
You can actually stack them, and because they're using power and ground as two of their pins,
clock and data as two of their other pins, they have a write protect pin, and then two
of the pins are address lines.
So, you can actually set these address lines, basically as a bootstrapping, you hardwire
the address lines, and then in the command frame to the serial EEPROM, you can address
an address.
You provide two address bits, so you can address up to four of them, which means you can stack
them and you can basically bust them together and get up to 256k bytes of storage in serial
EEPROM in a very small form factor.
Here's an example.
One of the nice things is because it's...
They're both eight-pin DIP packages, they share power and ground pins, so you can do
this little bug sex thing where you basically just stack them together.
In this case, I would actually...
To do what I want to do with it, I'd actually have to route some of the pins around with
some wires because this unfortunately puts one of the serial data lines on top of the
ATML interrupt line, which you want for the keyboard interface.
But I mean, if you look at it, it's pretty cool that you've got in the left-hand picture,
you have a microcontroller with 64k of flash hanging off it.
That's non-volatile memory.
The whole system runs at five volts and basically you could make that work with no other hardware
hanging off it.
The right-hand example is if you want to boost that up to 192k of flash.
I have the one pin...
That's one of the address lines and basically, I just wanted to provide an example of how
you...
If you don't want that pin connected, normally you would tag the pins together with solder,
but if you want a pin to go somewhere else, it's much easier.
It's really easy to just lift it up and run a wire off it.
Hmm.
Okay, so you've got an AT keyboard interface, you've got a large non-volatile memory, you've
got a tiny size, and you've got a bunch of people at DEF CON.
What could we build with this?
Now, at this point, I will go into a brief aside on a moral conundrum I found myself
in when preparing this talk.
It resolved itself in part because I was behind schedule and didn't get the thing completely
built.
But I was actually going to provide a reference design.
It was designed for a keyboard sniffer that anyone could build.
I read an article, though, about giving guns to children.
And it struck a chord with me that, you know, there should be a certain minimal sincerity
check to this.
You should at least have to build your own gun.
So I largely leave it at that, but the implication is you could build a really spiffy little
keyboard sniffer.
And...
And as to the question of how you get it out, how you get the data out, if you've seen the
Ghost Board, which is actually a commercial product that does this, and is in fact based
on...
I think it might be based on an AVR, I don't remember.
There's a web page, someone tore one apart and saw what's in there.
And they actually used a larger microcontroller.
I think this is a little slick, a little cooler solution, because it's just that much smaller.
I mean, you could probably make it look like just the keyboard connector.
But in their solution, they actually capture keystrokes and then output keystrokes.
And...
And you can actually just out the code, you can actually use the code as the means of
getting to it.
You actually type an activation sequence.
And since it's sniffing the AT keyboard interface, you can just use that to trigger it to have
it kick over and reveal that it's there and start dumping its log.
I would be inclined to actually make the thing completely transparent.
You want it to be completely out of band, so there is nothing you can type that would
make it reveal itself.
And also I would prefer to, given the number of pins and what I'd like to use them for,
I would probably actually set the hardware up.
so that I would have to drop it into a second fixture to extract the memory,
but that's just because I want to be the only one who can read it.
Anyway, so skipping, skipping, oh, yes, sure.
Yes, the question is, is there a security bit in the Atmel
that will prevent reading back the contents of the program memory?
And the answer is yes.
There's a couple of flash fuses that set different functionality,
but one of them is a security bit.
There's a read protect that will make it impossible to extract the contents.
There is also a write protect, I believe, that makes it impossible to overwrite it,
although you can still erase it if you want to,
so you don't end up turning it into a one-time programmable part.
But anyway, it depends on the specific part, but check the data sheet.
There are definitely things you can do to make your code,
I won't say impossible to extract,
but you can require them to shave off the top of the part
and use really expensive probing equipment.
And there are some really neat probing tools.
So audio output.
There is a proud history with 8-bit systems of generating audio
by twiddling one bit to a speaker.
Anyone who grew up with an Apple II
knows that you can...
You can do some pretty amazing things with one bit to a speaker.
You can also use a lookup table to generate a more pure tone,
and I talk about using a lookup table in either EEPROM
or using load program memory.
You may be wondering how...
If you've only got one bit going out,
how do you get anything other than on or off,
and I'll talk about that in just a second.
With program space, I talked about this briefly earlier,
but the way you extract your lookup tables from program spaces
with the LPM command,
you put the address you're looking for in the Z register,
which is basically the R30 and R31,
and then because of the way they want to represent the program memory
as a 16-bit word,
they call the upper 15 bits the word address
and the lower bit the byte select,
which is the same as saying a byte address,
but that's the way they represent it.
But basically, it means that you can store constants efficiently
in the 16-bit flash code space.
So you can store lookup tables
even though you don't have the EEPROM in this particular part.
Morse code, like I said, is a real canonical audio interface.
It's kind of cool because it represents a fairly well-known audio output,
and it's kind of nice to have your part alert itself
that it needs to do something by just going .
An interesting exercise when you're working with a system with no space,
such as this, or minimal space,
is how do you encode Morse code
for your lookup table to do the ASCII to Morse conversion?
And I touch on this just because it's a neat example
of figuring out how to store things really efficiently.
Morse is essentially binary in that you've got short and long,
but you've got variable length symbols
anywhere from E and T, which are 1,
up to some of the punctuation, which I believe are 6 or 7.
I don't remember if there's any 7 punctuation.
If you use a counter and a bitmap,
then you quickly run out of bits for anything longer than 5.
And I talk about L.
There you could use the 4 and then a bitmask,
and you could concatenate them together using 3 bits of length
and 5 bits of data.
Or you could use 0 null bits at the start,
a 1 start bit, and then the bitmask after that,
in which case you've managed to reduce the length indicator to 1 bit.
And this struck me as something that's not a big deal,
not immediately obvious, but is a nice efficient way
of storing things that are variable length
and little lookup tables.
So I felt compelled to include that.
Okay, DTMF.
Say instead of a Morse application,
you want to be able to dial a phone.
Atmel has an application note for you.
AVR 314.
They do it in 260 bytes of code and 128 byte lookup table.
The lookup table is basically just a representation
of the pulse width modulation constants for a sine wave.
And what you do is you output variable length constant values
on the speaker pin, and then you take advantage of the fact
that there is a characteristic capacitance to act as a low pass filter.
And so what you do is by turning the speaker on and off faster
than it could possibly represent in audio,
you get the low pass equivalent of that,
which turns into a sine wave or something close enough to it
that you can actually do fairly pure tones.
You can do tones pure enough to do DTMF.
In this case, the example in the data sheet
uses a pulse width modulation feature
that is included on a lot of the timer counters on the larger AVRs.
In this case, there is a timer counter,
but there is no pulse width modulation feature to it,
so you would have to jerry-rig that in software,
but it can be done.
And that's how you can do pure tones.
Obviously, if you want to do complex sounds,
you would need a much larger external memory.
But again, if you've got, say, a 64k K-byte phone,
and you've got flash memory hanging off it,
you could actually do a pulse width modulation representation
of more complex waveforms to generate more complex sounds.
Soft UART.
Say you want your device to be able to talk to the outside world
in an obvious way.
Application note AVR 304 is a really complete,
interrupt-driven, timer-based UART.
It takes several hundred words of code space,
you eat up a good chunk of your code space,
but you end up with a UART that is unobtrusive,
sits in the background,
uses the interrupt pin to detect start bits,
and then samples based on the timer.
All of these, if you're going to hook them up to, say, an RS-232 port,
are going to require an external transceiver
to do the level shifting from 0 to 5 to 0 to 12.
But those are readily available.
Or if you've got a system that's all things you've built,
you can just keep it all at 5-volt signaling.
I believe that's RS-422 or something.
What?
422 is balanced.
Okay, 422 is balanced, thank you.
Yes?
The clock is somewhat unstable.
He asks, the clock is somewhat unstable.
Do you use a crystal to clock it?
And again, the audience is getting ahead of me.
If you wait just about two more slides,
I will, in fact, address that.
But yes, there are definitely clocking problems
on an asynchronous interface that you have clock drift.
And there's a couple of ways around that.
If you want a minimal software UART,
application note AVR-305 is 32 words,
busy wait loops, no interrupt, no timer,
quick and dirty, and it's really kind of cool.
Basically, there's one hard-coded busy wait delay loop
that's half a bit time long
for whatever bit speed you want the thing to accommodate,
and then it just does shift register,
work, and calling this delay loop one, two, or three times,
depending on how many half-bit delays it needs.
And that's a good example of sort of sexy little,
very small, efficient coding for microcontrollers.
I mean, 32 words for a UART is pretty neat.
Some thoughts on software UARTs.
At high bit rates, your clock alignment
with whatever baud rate you're trying to support
will get worse and worse, and as was brought up,
the clocking is only as stable as a system clock.
Beware of the internal oscillator.
If you're using a part like this running at one megahertz,
you can theoretically do a UART that supports 38.4 k baud.
However, you probably want to bring that way back
because as your clock drifts,
the error gets more and more severe.
And you've got thermal drift, you've got voltage drift,
you've got manufacturing variations.
As I said, the AT12 also includes a calibrated clock
that you can use.
Yes?
Yes?
This is my own question.
Oh.
My question was, what's the baud rate
of the AT keyboard serial?
But then it's synchronous.
We've got to cooperate, so it doesn't really matter.
Yeah.
The AT keyboard is a synchronous interface
that can go up to 100 kilohertz,
but fortunately, you don't have to extract
your own clocking out of it.
Yes?
This is a weird question regarding the .
But is it possible to compare the internal clock
with the external clock in order to determine
how much the internal clock is drifting
to do thermal measurement with the die of the part?
Okay.
The question is, can you measure the internal clock
to an external clock to do thermal measurement
of the part with the clock drift?
Not that I am aware of.
I don't believe there is anything.
Well, it might be possible if you had an external counter
to do counter matching.
The trouble is, you can't get single clock resolution
for, it would be difficult to get single clock resolution
for doing comparisons.
It might be possible.
It's much cheaper to just stick a thermal measuring device
in the system.
Either a thermal diode or an explicit thermistor.
Another point you bring up though is clock drift,
if you do have a stable external reference
and you are willing to believe that clock drift
is truly random,
is a good source of randomness.
You can actually use clock noise
to feed your entropy buffer
if you are into that sort of thing.
So, data stream manipulation.
How am I doing?
Oh my.
Data stream manipulation, mod chips.
Like I said, I'm going to only touch on this.
If you do a search on AVR mod chips for the PlayStation,
you will find that there is someone
who actually has source code available online.
The way a mod chip works, at least in a PlayStation,
is you are just replacing the very low bitrate,
out-of-band serial stream
that says what the region code
for this particular disk is.
And what it does is instead spits out all of the region codes
so that any mod chip will work anywhere.
And the PlayStation hardware that reads this,
at least initially, was forgiving enough
to accept this sort of behavior.
Most of the mod chips that you can buy online
are implemented on the PIC device.
Like I said, there is at least one AVR available online.
And again, beware of clock deviation.
If you are going to do a mod chip,
you might want to do it on an AT12
which has a calibrated clock
because if you have thermal drift,
you can actually get far enough out
that your mod chip will stop working.
Some of the early generation mod chips
suffered from thermal failure
where as your PlayStation is on for half an hour,
it warms up and the thing no longer works.
PlayStation 2 mod chips are showing this behavior.
I know that there was also some effort
in the design of the PlayStation 2
to make it a little harder to do this sort of thing.
Obviously, in any system
where you have got the signals running around,
someone is going to figure out a way to get in there.
I think their goal is merely to make the mod chip
more expensive than the PlayStation.
And that may well happen.
And then I talked briefly about doing an IR receiver
if you want to be able to build
a wireless remote control application.
Philips Sony RC5 protocol is explained in AVR 410.
It is similar to a soft UART,
except it uses biphase or Manchester encoding
where there is a transition on every bit time.
That means that a high to low transition is a zero.
A high to low transition with the transition
in the middle of the bit is a zero.
A low to high is a one.
The reason you do this is because it is easier
to spot transitions than long runs of constant value,
especially in a medium like IR.
It also means that the signal is self-clocking.
You don't have to maintain clock synchronization
over many bit times.
It takes an input from an external IR diode
and the IR diode is actually available on this board.
And then the RC5 framing,
and they get into this in the data sheet,
but I just wanted to mention it,
is two start bits, which are always ones,
a control bit, which is toggled every time
any particular button is pressed,
five address bits, because of course you want
two to the fifth devices to control with your remote,
and six command bits, because of course
you've got that many devices.
What do you have to say to that many?
And then the small parallel example
is a stepper motor controller.
And I include this because there was actually
a lot of interest in doing servo designs
at last year's talk, and stepper motors
are really nice because once you understand
what they're doing, they're fairly easy,
they are open loop control mechanisms
that are still deterministic.
If you try to run a DC motor and you turn it on
for one second, you have no idea how many times
it's gone around, and you can gear it way down,
but you still don't know exactly how far you've moved.
With stepper motors, as long as you don't overload them,
they have moved as many steps as you've clocked,
and so it's open control loop.
You don't need an encoder on the shaft,
but you still know where the thing is.
For a unipolar stepper motor, the control is trivial.
For a dual polar, you actually have the possibility
of building a software-destroyable system,
and I'll talk about that in just a second.
A unipolar drive is commonly called
a six-wire stepper motor, where you've got
a center tap on each of two coils in the magnet,
and then you've got the end taps,
and you want to turn on one or the other end tap
to change the polarity on either of the coils.
There is a datasheet that I reference here at Ericsson,
which is a great introduction to stepper motor control.
I just swiped some diagrams from them,
and if you're interested in building a servo,
I'd recommend you go there and look at it.
If you're using a bipolar, you have a coil.
It's a four-wire stepper motor,
and you want to be able to reverse the polarity across the coil.
So what you do is you build what's called an H-bridge driver,
and if you look at this,
the alternate corners of the H-bridge are controlled by the same bit,
so it's still only four control bits required for an H-bridge,
but if you look at it,
you'll also notice a really nasty failure mode.
If you turn on both sets of switches on any H-bridge,
you suddenly have a very low impedance path from VCC to ground,
and the thing will emit light, smoke, or fire,
depending on how much power you're putting into it.
So what if you want more I.O.?
Well, then you may want to look at other parts.
What are you doing with an 8-pin part if you want more I.O.?
But if you are some kind of sadist,
you can use serial-to-parallel shift registers,
and in fact, there's some examples of this in really old LED signboards,
where they actually control a large multi-hundred LED array
with essentially two pins
by just shifting everything out into shift registers,
and then if you want your transitions on these shift registers to be clean,
make sure to use one with output latches,
and then it takes a third pin because you've got to clock the output latch,
but you can chain these things together and have an arbitrary number of I.O.s,
but the parts are so cheap for the larger parts,
you might as well just use a larger controller.
How do I blah for anything I have failed to mention here?
And there is an infinite number of things I've failed to mention here.
Hit the web.
If you search, you'll be amazed that there's...
Chances are, if you've got a great idea, someone else has already built it,
or at least has thought about building it.
Also, the manufacturer application notes, as you may have gotten an idea from my presentation,
provide a lot of good reference designs.
Often, if you look at manufacturers of parts that aren't the one you're working on,
you will find someone who's doing it on some other part,
and then you can port it over to your architecture of choice,
or change parts, depending on how agnostic you are.
You know, maybe there's a reason they chose a PIC,
or maybe there's a reason they chose an 8051, or some other part.
Or finally, if you don't find what you're looking for, create your own.
And please, share it with the world,
because that's how the next guy who goes out looking on the web finds your project.
If you're looking for a starter book,
the kit is the hardware you need.
The kit doesn't provide a good first-order reference.
I finally...
Last year, a lot of people were asking for a book,
and there's a book called Get Going with AVR by Peter Sharpe.
It's written in British, so it's got a few strange words in it,
but it's a really good explanation.
It starts at very low-level stuff,
and it will explain to you what binary is,
but it gets past that by about page four.
And then it really does get into some interesting applications.
It shows you how to make good use of the hardware.
It's designed around a slightly different Canda development board,
but you should be able to make the transition fairly painlessly.
Do read the documentation for this stuff,
because there are some quirks to the STK100.
The control device, which is the...
There's actually a microcontroller on there
that it uses to send the code to your device through.
It's basically an in-system program controller.
It actually controls the...
the voltage that the processor runs at.
And it took me the longest damn time to figure this out.
In spite of looking at the schematics,
I was really embarrassed that I could not figure out
why the thing would run three times faster
when it was in run mode than in program mode
until I realized three.
Three. One megahertz, 350 kilohertz.
This sounds like the RC oscillator running at three volts.
Duh.
Also, the ISP software requires Intel hex files,
which is not the default of AVR Studio.
This was also the source of...
far more wasted time than it should have been for me.
So it's embarrassing, but I admit it here to...
to remind you that make sure the files you're generating...
Because I had generated one hex file,
generated one output file,
and then had failed to save that change to the AVR Studio.
So I could never figure out why my code,
no matter how I would change it,
didn't ever get better.
And it turns out I was downloading the same image
into the... into the part repeatedly.
Then...
chance for me to drink some water?
Okay.
I like to close these with an inspirational message.
And one of the things I always say,
like any... like any good project,
the hard part of these is getting started.
And this year I added the caveat that you should cheat
by starting with someone else's work.
Or... or a trivial example.
And I... I have some trivial examples I'm happy to give you.
I've got a very few minutes left in the talk,
so I'm probably not going to... to do a demo of the dev studio.
It's... it's pretty straightforward.
It's available online at the Atmel website for free.
I would encourage you to go take a look at it.
Even if you don't have the starter kit,
you can at least play with the simulator.
Start small and work up from there.
Be willing to make... make mistakes,
because that's... like I said,
I've tried to share my mistakes here,
but if you do something stupid,
at least you will only do it once.
Hopefully.
And then... and then get involved.
Join the community of developers.
There's a lot of people who are interested in this stuff.
And no matter how retarded your project is,
there's probably at least one other person on Earth
who thinks it's as cool as you.
So, to recap, microcontrollers,
a different development opportunity.
Gone over some of the characteristics of the AVR,
specifically the ATtiny11.
We've looked at a lot of example functions,
and then I've put the fun...
It's just fun to tinker with these.
It's neat to make blinking lights.
And then now is the chance to win the development environment.
I'll go into QA mode in just a second,
but if you would like to submit feedback,
I would... I would strongly encourage you
to give me feedback if you...
if you have...
a pen and paper.
If you don't, ask... ask the guy next to you.
Please write down your name or handle.
If you win one, it will be at the bellhop desk
with your name or handle on it in an hour.
Because I've got to read the project ideas.
Tell me what I should change about this talk.
If... if there's anything you would have liked to see more of, less of,
please tell me what... what I could do differently next year
if I... if I come back.
What, if anything, you liked about it.
This is less important to me,
but I ask this merely so I don't take out something good.
And then the important question for getting the development kit
is why do you want an STK100?
What's your cool project idea?
The feedback is important to me,
but the kits are awarded based on the project idea.
So even if you tell me I'm stupid, ugly, and I suck,
but you have a good project idea,
you will win a kit.
And like I said, winners can pick up theirs
at the bellhop desk out front.
It's the thing out in front of the...
It's... it's outside where you can check your bags,
and I will just stick your name on it and check it there.
And... and I'll try to post a list of the winning handles,
and I will get...
I'll give away any I don't give away here.
If you want to contact me,
my email address, pking at pkscientific.com,
and the... the subtle implicit plug for my not-an-agent jackets,
which I'm not selling at the moment anyway,
the website for this talk is notanagent.com,
and the slides and some of the examples
will be available on there shortly.
I'm also...
If you have other things you'd like me to add to the website,
please feel free to send them along.
There's an AVR web ring I may or may not add the site to,
but...
but there's a lot of project rings that you can find
if you just look around.
It's... it's a very fertile...
very fertile environment online.
So, Q&A.
Are there any general microcontroller questions,
AVR-specific, or...
or who wants to try and win something with a project idea?
Oh, sorry, yeah.
Hold on.
Yeah, that's...
that's the information I'm looking for
in terms of feedback.
Was there...
Yes.
Yeah.
Sorry, you.
For a project idea...
Project idea.
I have a little ambition.
Trying to take a basic Ethernet chip set,
somehow get it worked into a whole situation
and have a very basic, you know, kind of frame set of memories,
and then a simple type of keyboard interface
to input, you know, maybe an arbitrary UIC address
into the source, nothing too much.
And that way you could, you know,
plug it into a network.
A little bit smaller.
And then maybe your favorite IP and IP packet
would be good for an arbitrary host
and to an arbitrary destination.
A very small spam bot,
or IP storm bot.
So, his idea was an IP...
an IP packet spewer
based on a microcontroller
where you precompute the frame
and have it sitting in memory,
and have the thing hooked up to an Ethernet controller.
Hooking up to an Ethernet controller
is a few more pins than we have here,
but you could probably do it
with a couple of 8-pin ports.
What you've described in part is the PicoWeb.
I don't know if anyone is raising their hand
to mention this.
There actually is an AVR
to an ISA Ethernet controller device.
It's not designed to spew out packets
as fast as you want to.
It's designed to actually be a complete web server.
But let's get an audience approval rating.
Does a packet storm generator
based on a microcontroller and an Ethernet chip
merit a development box?
Yes? No? Yes?
Show of hands.
Everyone who thinks he should get one?
Everyone who doesn't?
Clock rate problems.
Clock rate problems.
Even at 10 megabits,
your 1 megahertz processor
is going to run fast enough
to spew those out.
But it might be running fast enough
if you've got an Ethernet controller
with onboard memory
to at least tell it,
send that frame again.
So for what it's worth,
I will at least concede
that you could build it.
Is there anyone speaking in his defense?
I have a solution
that will make this idea work.
A solution, okay.
We have a hardware
that we've got to keep that
so we can interface with SPI
and just use clock data.
Okay, it's a three-wire interface
to a hardware-based IP stack,
did you say?
Exactly.
Okay, well, so that makes it work.
You can actually look at a reference design
at ireddy.org.
So a reference design for that
available at ireddy.org.
So, okay, it sounds like it's going to work.
I think I'm going to give it to him.
Hold on a sec.
Could you hand that back?
Yeah, it's a big green box.
We can see it.
Okay, yes.
A single-key keyboard.
A single-key keyboard
for going from Morse code to AT
so that you can use it while driving
or roller skating.
I think that's a winner, yeah.
Let me recommend you use power
a lot faster than a single-key.
And if you're really ambitious
and want to stick four buttons on it,
you could do a nibble-based Cordic keyboard.
I always neglect the people in the back.
Let me try and find someone in the back.
See, the people in the back always get screwed.
You, the guy in the white.
Is that Free Geek?
Is that a label or a command?
Okay.
So, okay.
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The trouble that leaps to mind is at least with the minimal I.O.,
you're going to get one stepper motor, so you're going to have one degree of freedom,
which is a fairly limited robotic arm.
I'm going to be cruel and throw this one entirely to the audience,
and this time I'm actually going to listen to what they say.
Who thinks the robotic arm control for a tape farm should get it?
And not?
I'm sorry.
Submit a feedback form.
What?
Yeah, that's what eBay is for.
And another thing I would point out is if you get out of here and you've submitted a feedback form
and you still don't get one, call up Atmel and sound either really smart or really pathetic,
and there's a good chance that they will send you one,
especially if you're a student.
Ask to speak to the university liaison because they do like to get these things into schools,
or if you can just say you're a student.
Okay, the guy with both hands up in the gesture cap.
We've got a current budget going.
We're using the BS2SA, and we're using the DCMS app,
along with the voice recording app,
and we've got it hooked into a phone line where it'll dial the number and everything.
When the pulse beats drop and the other end picks up,
it'll automatically send a recording message and say whatever,
and that's it.
So it's an answering machine that calls out for you.
He's using DTMF and an external voice recorder chip to dial out
and wait for the other end to pick up and record.
Am I basically getting it right?
Okay, and it'll respond to DTMF tones from them.
A social engineering or telemarketing tool.
Okay.
Throwing it to the audience.
Does he get one?
Oh, I'm sorry.
Hostile crowd.
All right.
I'm pleased.
Am I just about out of time?
How much longer can I go?
Well, I haven't had any word of the next speaker.
That'd be me.
Okay.
There he is.
So we've got the next speaker.
We've got five minutes over, so I guess it's at his discretion now.
Okay, so I'm pretty much running out of time.
I'm going to take one more.
And again, the guy sort of toward the back in the blue cap.
Yeah.
Yeah.
Could you speak up?
I caught a link between a Game Boy and a PC with a link port.
Oh, okay.
Using the link port on the Game Boy Advance and basically building glue between that and a PC?
Ah.
Okay.
So would you be running games on the Game Boy or using the Game Boy as a terminal for the PC?
Okay, so it's a development project for basically the Game Boy as a console.
I don't know.
It sounds kind of cool.
What's the consensus?
All in favor?
All in favor?
All opposed?
Okay, the hostile people are less adamant.
I think you get one.
Can you come on up here at the end?
And if everyone could just bring feedback forms if you've got them up to me.
I'm going to wrap it up now so the next guy can speak.
But thank you very much.
You've been a great audience.
Thank you.
Thank you.
Thank you.
Thank you.
